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Abstract 


People  responsible  for  computer  security  incident  response  and  digital  forensic  examination  need 
to  continually  update  their  skills,  tools,  and  knowledge  to  keep  pace  with  changing  technology. 
No  longer  able  to  simply  unplug  a  computer  and  evaluate  it  later,  examiners  must  know  how  to 
capture  an  image  of  the  running  memory  and  perform  volatile  memory  analysis  using  various 
tools,  such  as  PsList,  ListDLLs,  Handle,  Netstat,  FPort,  Userdump,  Strings,  and  PSLoggedOn. 
This  paper  presents  a  live  response  scenario  and  compares  various  approaches  and  tools  used  to 
capture  and  analyze  evidence  from  computer  memory. 


V  I  CMU/SEI-2008-TN-017 


Vi  I  CMU/SEI-2008-TN-017 


Introduction 


It  is  no  longer  sufficient  when  gathering  digital  evidence  to  pull  the  plug  and  take  the  machine 
back  to  the  lab.  As  technology  continues  to  change,  incident  responders  and  digital  forensic 
examiners  must  adopt  new  methods  and  tools  to  keep  up.  This  is  applicable  especially  in 
situations  such  as  a  live  response  scenario.  For  instance,  with  standard  RAM  size  between  two 
and  eight  gigabytes,  the  migration  of  malware  into  memory,  and  the  increasing  use  of  encryption 
by  adversaries,  it  is  no  longer  possible  to  ignore  computer  memory  during  an  acquisition  and 
subsequent  analysis. 

Traditionally,  the  only  useful  approach  to  investigating  memory  was  a  live  response.  This 
involved  querying  the  system  using  API-style  tools  familiar  to  most  network  administrators.  The 
first  responder  was  looking  for  rogue  connections  or  mysterious  running  processes.  It  was  also 
possible  to  capture  an  image  of  the  running  memory,  but  until  recently,  short  of  a  string  search,  it 
was  difficult  to  gather  useful  data  from  a  memory  dump.  The  past  few  years  have  seen  rapid 
development  in  tools  focused  exclusively  on  memory  analysis. 

This  paper  is  organized  into  five  sections: 

Section  1  presents  a  scenario  in  which  useful  evidence  can  be  collected  from  a  running  machine. 

Section  2  describes  a  live  response  approach  to  the  scenario. 

Section  3  describes  a  volatile  memory  analysis  approach  to  the  scenario. 

Section  4  discusses  the  drawbacks  of  both  approaches  and  discusses  which  analysis  approach 
provides  a  more  viable  investigation  process. 

Section  5  presents  a  conclusion. 
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1  Scenario 
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Figure  1:  Live  response  with  Sys-Internal  tools  vs.  memory  analysis  on  a  static  memory  dump 


The  traceability  matrix  of  Figure  1  is  a  mapping  of  the  capabilities  of  live  response  and  memory 
analysis  tools  during  an  investigation  of  a  memory  image  (or  running  memory).  The  Live 
Response  part  of  Figure  1  lists  the  tools  used  in  live  response,  and  the  Memory  Analysis  part 
shows  tools  that  analyze  physical  memory  dumps.  This  section  contains  hints  for  creating  and 
maintaining  Word  files  and  suggestions  for  avoiding  common  mistakes. 

In  our  virtual  environment  scenario,  we  start  with  a  Windows  XP  Service  Pack  2  virtual  machine 
with  an  IP  address  of  192.168.203.132.  Netcat  was  used  to  establish  a  telnet  connection  on  port 
4444  (PID:  3572)  with  a  second  machine  at  192.168.203.133.  MACSpoof  was  also  installed  and 
running  (PID:  3008).  This  machine  was  then  compromised  by  installing  the  FUTo  rootkit  and  a 
ProRat  server  listening  on  port  5 1 10.  The  netcat  and  MACSpoof  processes  were  then  hidden 
using  the  FUTo  rootkit. 

In  the  following  sections,  we  present  two  possible  techniques  to  approach  the  compromised 
system  and  we  discuss  what  details  are  visible  and  invisible  concerning  the  various  compromises 
using  each  approach.  The  first  approach  we  present  is  a  live  response  process  using  sys-intemal 
style  tools.  The  second  is  a  static  memory  dump  analysis  using  open  source  memory  analysis 
tools.  Finally,  we  discuss  the  benefits  and  drawbacks  of  both  approaches. 
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2  Live  Response 


The  first  approach  is  live  response.  Here  an  investigator  would  first  establish  a  trusted  command 
shell.  In  addition,  they  would  establish  a  method  for  transmitting  and  storing  the  information  on  a 
data  collection  system  of  some  sort.  One  option  is  to  redirect  the  output  of  the  commands  on  the 
compromised  system  to  the  data  collection  system.  One  popular  tool  is  netcat,  a  network  utility 
that  transmits  data  across  network  connections.  Another  approach  would  be  to  insert  a  USB  drive 
and  write  all  query  results  to  that  external  drive.  Finally,  investigators  would  attempt  to  bolster  the 
credibility  of  the  tool  output  in  court.  During  a  live  interrogation  of  a  system,  it  is  important  to 
realize  that  the  state  of  the  running  machine  is  not  static.  This  could  lead  to  the  same  query 
producing  different  results  based  on  when  it  is  run.  Therefore,  hashing  the  memory  is  not 
effective.  Rather,  an  investigator  could  compute  a  cryptographic  checksum  of  the  tool  outputs  and 
make  a  note  of  this  hash  value  in  the  log.  This  would  help  dispel  any  notion  that  the  results  had 
been  altered  after  the  fact.  In  this  exercise,  HELIX  (a  live  response  and  Linux  bootable  CD),  was 
used  to  establish  a  trusted  command  shell. 


Figure  2:  Trusted  command  shell  established  using  HELIX 


Once  the  above  data  collection  setup  is  complete,  an  investigator  can  begin  to  collect  evidence 
from  the  compromised  system.  The  sys-intemal  style  tools  used  in  this  exercise  are  not  meant  to 
be  an  exhaustive  list.  Rather,  they  are  representative  of  the  types  of  tools  available.  The  common 
thread  for  the  tools  used  is  that  each  relies  on  native  API  calls  to  some  degree,  and  thus  the  results 
are  filtered  through  the  operating  system.  The  tools  used  in  this  case  were  PsList,  ListDLLs, 
Handle,  Netstat,  FPort,  Userdump,  Strings,  and  PSLoggedOn. 
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Figure  3:  Results  from  psiist 


PsList  allows  investigators  to  view  process  and  thread  statistics  on  a  system.  Applying  PsList 
reveals  all  running  processes  on  the  system  but  does  not  reveal  the  presence  of  the  rootkit  or  the 
other  processes  that  the  rootkit  has  hidden  (netcat  and  MACSpoo:Q. 
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ListDLLs  v2.25  -  DLL  lister  for  Win9x/NT 

Copyright  (C)  1997-2004  Mark  Russinovich 

Sys interna  Is  -  www.sysinternals.cotn 

System  pid:  4 

Command  line: 

■iTiO  command  line> 

smss.exe  pid: 

608 

Command  line: 

\SystemRoot\System32\smss .exe 

Base 

Size  Version 

Path 

0x48580000 

0Xf000 

\Sy stemRoot \Sy stem32 \smss . exe 

0X7C900000 

0xb0000  5.01.2600.2180 

C:\WI NDOWS \system32 \ntd 1 1 . d 1 1 

csrss.exe  pid 
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SharedSection* 

*1024,3072,512  WindowssOn  SubSystemTypesWindows  ServerDl Ubasesrv,! 

Ser ver D 1 1 sw i nsrv : User Server D 1 1 1 n i t i a  1 i zat i on , 3  Ser ver D 1 1 sw i nsr v : ConSer ver D 1 1 1 n i t i a  1 i zat i on , 2 

Prof i 1 eContr 0 1 sOf  f  HaxRequestThreadSsl6 

Base 

Size  Version 

Path 

0x4a680000 

0X5000 

\?? \C :  \W I NDOWS \sy stem32 \csrss . exe 

0X7C900000 

0xb0000  5.01.2600.2180 

C:\WI NDOWS \system32 \ntd 1 1 . d 1 1 

0x75b40000 

0xb000  5.01.2600.2180 

C:\WI NDOWS \system32 \CSRSRV .dll 

0x75b50000 

0x10000  5.01.2600.2180 

C:\WI NDOWS \system32 \basesrv .dll 

0x75b60000 

0x4b000  5.01.2600.3103 

C:\WI NDOWS \system32 \w i nsrv .dll 

0x77fl0000 

0x47000  5.01.2600.3316 

C:\WI NDOWS \system32 \GDI32.dll 

Figure  4:  Excerpt  from  ListDLLs  output 


ListDLLs  allows  investigators  to  view  the  currently  loaded  DLLs  for  a  process.  Applying 
ListDLLs  reveals  the  DLLs  loaded  by  all  running  processes.  However,  since  there  are  processes 
that  are  hidden,  ListDLLs  cannot  show  the  DLLs  loaded  for  them.  Thus,  critical  evidence  that 
could  reveal  the  presence  of  the  rootkit  is  missed.  The  problem  is  that  an  attacker  may  have 
compromised  the  Windows  API  upon  which  an  investigator’s  toolkit  depends.  To  a  degree,  this  is 
the  case  with  our  scenario.  As  a  result,  rootkit  manipulation  cannot  be  easily  detected  with  these 
tools.  A  more  sophisticated  and  non-intrusive  approach  is  necessary  to  find  what  could  be  critical 
evidence. 


rue  {KV- ) 

L :  \wiNuuwo \winaowsupaace . log 

cmd.exe  pid:  3540  U3ER-D6520207A3\Administrator 

64: 

Fi  le  (RW-) 

C:\WI NDOWS \W i nSxS \x86_M i crosof  t , W i ndows , Common-Contr o 1 s_6595bi 

CO 
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Figure  5:  Excerpt  from  Handle  output 
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The  Handle  utility  allows  investigators  to  view  open  handles  for  any  process.  It  reveals  the  open 
files  for  all  the  running  processes,  which  includes  the  path  to  the  file.  In  this  case,  one  of  the 
command  shells  is  running  from  a  directory  labeled  . .  .\FUTo\EXE.  This  is  a  strong  hint  of  the 
presence  of  the  FUTo  rootkit.  Similarly,  there  is  another  instance  of  cmd.exe  running  from 
C:\tools\ncl  Int.  The  ncl  Int  folder  is  a  default  for  the  windows  distribution  of  netcat.  While  it  is 
useful  to  show  the  implications  of  the  tool  results,  it  is  important  to  remember  that  simply 
renaming  these  directories  or  running  the  cmd.exe  from  a  different  directory  would  have 
prevented  these  disclosures. 
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Figure  6:  Netstat  results 


The  Netstat  utility  allows  investigators  to  view  the  network  connections  of  a  running  machine. 
Nestat  (with  the  -an  option)  reveals  nothing  immediately  suspicious  in  this  case. 
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FPort  v2.0  -  TCP/IP  Process  to  Port  Mapper 
Copyright  2000  by  Foundstone,  Inc. 
http : //WWW . f  oundstone . com 
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0 

System 

-> 

1900 

UDP 

3144 

services 

-> 

4500 

UDP 

C:\WI NDOWS \serv i ces  .exe 

Figure  7;  Results  of  FPort 


FPort  allows  investigators  to  view  all  open  TCP/IP  and  UDP  ports  and  maps  them  to  each 
process,  which  includes  the  PID  and  the  executable  path.  In  our  scenario,  FPort  does  not  reveal 
the  presence  of  the  connections  hidden  by  the  rootkit. 

Userdump  allows  investigators  to  extract  the  memory  dumps  of  running  processes  for  offline 
analysis.  Since  it  has  a  specific  meta-data  format,  dumpchk.exe 

(http://support.microsoft.com/kb/315271)  is  normally  used  to  verify  that  a  usable  process  memory 
dump  was  produced.  The  Strings  utility  extracts  ASCII  and  UNICODE  characters  from  binary 
files.  In  this  case,  an  investigator  would  apply  it  to  the  process  dumps  and  see  what  evidence  can 
be  uncovered. 

Finally,  PsLoggedOn  helps  investigators  discover  users  who  have  logged  in  both  locally  and 
remotely.  In  this  case,  only  the  Administrator  is  logged  on. 
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3  Volatile  Memory  Analysis 


The  second  approach  is  volatile  memory  image  analysis.  It  is  similar  to  live  response,  in  that  an 
investigator  would  first  establish  a  trusted  command  shell.  Then  they  would  establish  a  data 
collection  system  and  a  method  for  transmitting  the  data.  However,  an  investigator  would  only 
acquire  a  physical  memory  dump  of  the  compromised  system  and  transmit  it  to  the  data  collection 
system  for  analysis.  In  this  case  VMware  allows  investigators  to  simply  suspend  the  virtual 
machine  and  use  the  .vmem  file  as  a  memory  image.  As  established  in  digital  forensic  practices, 
an  investigator  would  also  compute  the  hash  upon  completion  of  the  memory  capture.  Unlike 
traditional  hard  drive  forensics,  no  hash  is  calculated  for  memory  before  acquisition.  Due  to  the 
volatile  nature  of  running  memory,  the  imaging  process  is  taking  a  snapshot  of  a  “moving  target.” 


The  primary  difference  between  this  approach  and  Live  Response  is  that  no  additional  evidence  is 
needed  on  the  compromised  system.  Therefore,  the  evidence  can  be  analyzed  on  the  collection 
system. 


As  seen  in  Figure  1,  we  discuss  the  capabilities  of  two  memory  analysis  tools  applied  on  the 
memory  image.  We  also  describe  what  evidence  is  visible  to  an  investigator  in  this  type  of 
analysis.  The  tools  used  are  The  Volatility  Framework  by  Volatile  Systems  and  PTFinder  by 
Andreas  Schuster.  The  capabilities  of  each  tool  are  discussed  as  well  as  the  information  it  extracts 
from  memory  dumps.  These  tools  are  recent  additions  to  the  excellent  array  of  open  source 
resources  available  to  digital  investigators.  There  are  other  memory  analysis  tools  not  included  in 
this  comparison. 


3.1  VOLATILITY 


The  Volatility  Framework  is  a  collection  of  command-line  python  script  that  analyzes  Windows 
XP  Service  Pack  2  memory  images.  It  allows  an  investigator  to  interrogate  the  image  in  a  style 
similar  to  that  used  during  a  live  response.  Volatility  is  distributed  under  a  GNU  General  Public 
License.  For  this  exercise  version  1.1.2  was  used.  It  allows  an  investigator  to  interrogate  the 
image  in  a  style  similar  to  that  used  during  a  live  response.  Commands  available  in  the  1.1.2 
version  include  i  dent,dateti  me,psl  i  st,psscan,thrdscan,dl  I  I  i  st,modul  es, 
sockets, sockscan,connecti  ons,connscan,vadi  nfo,vaddump, and  v  a  d  wa  I  k . 
Several  of  the  commands  used  during  the  exercise  are  explained  below. 

Using  the  syntax  python  volatility  ident  -f  WinXP_victim.  vmem  and  python 
volatility  d  a  t  e  1 1  me  -  f  Wi  n  X  P  _  v  I  c  1 1  m.  v  me  m,  the  I  d  e  n  t  and  d  a  t  e  1 1  me  commands 
are  used  to  gather  information  about  the  image  itself  (in  this  case  the  image  used  was  the 
WinXP_victim.vmem  file).  The  first  provides  the  operating  system  type,  virtual  address 
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translation  mechanism,  and  a  starting  directory  table  base  (DTB),  while  the  second  reports  the 
date  and  time  the  image  was  captured.  This  provides  valuable  information  because  it  assists  with 
documentation  purposes  in  a  digital  investigation.  Furthermore,  it  is  useful  for  creating  a  timeline 
of  events  with  other  pieces  of  evidence  in  the  digital  investigation. 


Name 

Pld 

PPld 

Thds 

Hnds 

Time 

System 

4 

e 

55 

405 

Thu 

Oan 

01 

00:00:00  1970 

smss.exe 

608 

4 

3 

21 

Wed 

3ul 

09 

21:36:12  2008 

csrss.exe 

656 

608 

12 

473 

Wed 

Jul 

09 

21:36:13  2008 

winlogon.exe 

680 

608 

19 

515 

Wed 

aul 

09 

21:36:14  2008 

servlces.exe 

724 

680 

16 

363 

Wed 

Jul 

09 

21:36:15  2008 

lsass.exe 

736 

680 

18 

343 

Wed 

Jul 

09 

21:36:16  2008 

vmacthlp.exe 

896 

724 

1 

24 

Wed 

Oul 

09 

21:36:17  2008 

svchost.exe 

912 

724 

16 

192 

Wed 

3ul 

09 

21:36:17  2008 

svchost.exe 

1016 

724 

9 

270 

Wed 

3ul 

09 

21:36:20  2008 

svchost.exe 

1112 

724 

75 

1323 

Wed 

3ul 

09 

21:36:20  2008 

svchost.exe 

1168 

724 

6 

81 

Wed 

Jul 

09 

21:36:21  2008 

svchost.exe 

1308 

724 

15 

212 

Wed 

Jul 

09 

21:36:21  2008 

ccSetHgr.exe 

1508 

724 

7 

190 

Wed 

Jul 

09 

21:36:22  2008 

ccEvtHgr.exe 

1552 

724 

16 

288 

Wed 

Jul 

09 

21:36:23  2008 

SPBBCSvc.exe 

1640 

724 

15 

243 

Wed 

Jul 

09 

21:36:24  2008 

spoolsv.exe 

1716 

724 

11 

116 

Wed 

Jul 

09 

21:36:24  2008 

Rtvscan.exe 

648 

724 

52 

581 

Wed 

Jul 

09 

21:36:31  2008 

VMwareServlce.e 

1224 

724 

3 

56 

Wed 

Jul 

09 

21:36:33  2008 

explorer.exe 

2468 

2392 

13 

504 

Wed 

Jul 

09 

21:37:34  2008 

VMwareTray.exe 

2616 

2468 

1 

27 

Wed 

Jul 

09 

21:37:39  2008 

VMwareUser.exe 

2632 

2468 

4 

156 

Wed 

Jul 

09 

21:37:39  2008 

ccApp.exe 

2640 

2468 

10 

242 

Wed 

Jul 

09 

21:37:39  2008 

wuaucLt.exe 

3072 

1112 

4 

166 

Wed 

Jul 

09 

21:37:49  2008 

cmd.exe 

3540 

2468 

1 

31 

Wed 

Jul 

09 

21:38:54  2008 

cmd.exe 

3796 

2468 

1 

31 

Thu 

Jul 

10 

19:00:22  2008 

servlces.exe 

3144 

3132 

3 

85 

Thu 

Jul 

10 

19:04:48  2008 

cmd.exe 

3816 

2468 

1 

31 

Thu 

Jul 

10 

19:49:21  2008 

cmd.exe 

2032 

1224 

0 

-1 

Thu 

Jul 

10 

19:52:21  2008 

Figure  8:  Results  from  Volatility  psiist  command 


Using  the  p  S I  i  St  command  produces  results  similar  to  Sysintemal  pslist.exe  tool  used  during 
the  live  response. 
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System  pid: 

4 

Unable  to  read  PEB  for 

task. 

smss.exe  pid 

:  608 

Command  line 

:  \SystemRoot\System32\smss.exe 

Base 

Size 

Path 

0x48580000 

0Xf000 

\SystemRoot\System32\smss .exe 

0X7C900000 

0Xb0000 

C:\WI NDOWS \system32 \ntd 1 1 .  d  1 1 

csrss.exe  pid:  656 

Command  line 

:  C:\WIND0WS\system32\csrss.exe  ObjectDirectory=\Windows  SharedS^ 

ServerD 1 l=winsrv lUserServerD 1 1 Initia 1 ization ,3  ServerD 1 Uwinsrv  rConServerD 1 1 Ii 

Base 

Size 

Path 

0x4a680000 

0X5000 

\??\C:\WIND0WS\system32\csrss,exe 

0x7c900000 

0Xb0000 

C:\WI NDOWS \system32 \ntd 1 1 .  d  1 1 

0x75b40000 

0Xb000 

C:\WI NDOWS \system32 \CSRSRV .dll 

0x75b50000 

0x10000 

C:\WI NDOWS \system32 \basesrv , d 1 1 

0x75b60000 

0x4b000 

C : \WIND0WS\system32\winsrv  .d  1 1 

0x77f 10000 

0x47000 

C:\WI NDOWS \system32 \GDI32.dll 

Figure  9:  Volatility  dlllist  results 


This  is  also  the  case  with  the  dlllist  command.  This  option  shows  the  size  and  path  to  all  the 
DLLs  used  by  each  running  process. 
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Fast 

No. 

PID 

Time  created 

Time  exited  Offset 

PDB 

Remarks 

1 

2 

0 

3816 

Thu 

Jul 

10 

19 

49 

21 

2008 

0x00551d80 

0x01f4e020 

0X0031a000 

0xla5402a0 

Idle 

cmd.exe 

3 

3540 

Wed 

Jul 

09 

21 

38 

54 

2008 

0x01fb25e0 

0xla540400 

cmd.exe 

4 

3072 

Wed 

Jul 

09 

21 

37 

49 

2008 

0x01fdb5b0 

0xla540320 

wuauclt.exe 

5 

3144 

Thu 

Jul 

10 

19 

04 

48 

2008 

0x01fef020 

0xla540460 

services.exe 

6 

2616 

Wed 

Jul 

09 

21 

37 

39 

2008 

0x02056020 

0xla540100 

VHwareTray.exe 

7 

648 

Wed 

Jul 

09 

21 

36 

31 

2008 

0x020fcda0 

0xla540240 

Rtvscan.exe 

8 

724 

Wed 

Jul 

09 

21 

36 

15 

2008 

0x0217b5a8 

0xla540080 

services.exe 

9 

1716 

Wed 

Jul 

09 

21 

36 

24 

2008 

0x02190da0 

0xla540200 

spoolsv.exe 

10 

1168 

Wed 

Jul 

09 

21 

36 

21 

2008 

0x021a6990 

0xla540160 

svchost.exe 

11 

1508 

Wed 

Jul 

09 

21 

36 

22 

2008 

0x021a9020 

0xla5401a0 

ccSetMgr.exe 

12 

2032 

Thu 

Jul 

10 

19 

52 

21 

2008 

Thu  Jul  10  19:52:22  2008  0x021d0358 

0xla540220 

cmd.exe 

13 

2632 

Wed 

Jul 

09 

21 

37 

39 

2008 

0x021d93a0 

0xla540360 

VHwareUser.exe 

14 

2640 

Wed 

Jul 

09 

21 

37 

39 

2008 

0x021fdda0 

0xla540380 

ccApp.exe 

15 

736 

Wed 

Jul 

09 

21 

36 

16 

2008 

0x0235a020 

0xla5400a0 

lsass.exe 

16 

2468 

Wed 

Jul 

09 

21 

37 

34 

2008 

0x0235e7b0 

0xla540340 

explorer.exe 

17 

1552 

Wed 

Jul 

09 

21 

36 

23 

2008 

0x023edda0 

0xla5401c0 

ccEvtMgr.exe 

18 

1640 

Wed 

Jul 

09 

21 

36 

24 

2008 

0x023fd9a0 

0xla5401e0 

SPBBCSvc.exe 

19 

656 

Wed 

Jul 

09 

21 

36 

13 

2008 

0X02401C08 

0xla540040 

csrss.exe 

20 

680 

Wed 

Jul 

09 

21 

36 

14 

2008 

0x024205f0 

0xla540060 

winlogon.exe 

21 

1308 

Wed 

Jul 

09 

21 

36 

21 

2008 

0X0242C888 

0xla540180 

svchost.exe 

22 

1112 

Wed 

Jul 

09 

21 

36 

20 

2008 

0x0242cb08 

0xla540140 

svchost.exe 

23 

1016 

Wed 

Jul 

09 

21 

36 

20 

2008 

0x02436bl0 

0xla540120 

svchost.exe 

24 

912 

Wed 

Jul 

09 

21 

36 

17 

2008 

0x0243e250 

0xla5400e0 

svchost.exe 

25 

1224 

Wed 

Jul 

09 

21 

36 

33 

2008 

0x02458da0 

0xla540260 

VMwareService.e 

26 

3796 

Thu 

Jul 

10 

19 

00 

22 

2008 

0x02490170 

0xla5402e0 

cmd.exe 

27 

896 

Wed 

Jul 

09 

21 

36 

17 

2008 

0x024a86a8 

0xla5400c0 

vmacthlp.exe 

28 

0 

Thu 

Jul 

10 

18 

59 

55 

2008 

0x024fb020 

0xla5402c0 

MACSpoof .exe 

29 

608 

Wed 

Jul 

09 

21 

36 

12 

2008 

0x02578408 

0xla540020 

smss.exe 

30 

4 

0x026c8830 

0x0031a000 

System 

Figure  10:  Volatility  psscan  command  shows  MACSpoof.exe 


However,  when  we  use  the  p  S  S  C  a  n  option  something  new  is  revealed.  With  a  PID  of  0 
MACSpoof.exe  shows  up  in  the  list.  This  command  scans  for,  and  returns,  the  physical  address 
space  for  the  all  EPROCESS  objects  found. 


Local  Address 

Remote  Address 

Pid 

127.0.0.1:1114 

127.0.0.1:1033 

3144 

192.168.203.132:1076 

64.236.22.201:80 

1004 

192.168.203.132:4444 

192.168.203.133:2867 

3572 

127.0.0.1:1033 

127.0.0.1:1114 

2640 

Figure  1 1:  Volatility  connscan  resutls 


While  netstat  failed  to  provide  any  sign  of  the  netcat  activity,  using  connscan  shows  us  the 
connection  with  192.168.203.133  on  port  4444.  The  results  also  indicate  a  PID  of  3572  associated 
with  this  connection.  The  fact  that  this  PID  is  missing  from  the  other  queries  could  indicate  the 
presence  of  a  rootkit. 
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Name 

Base 

\W I NDOWS \system32 \ntkrn 1 pa . exe 

0x804d7000 

\WIND0W3\system32\ha 1 .d 1 1 

0x806ce000 

\WIND0WS\system32\KDC0M .DLL 

0xf8b9a000 

\W  I  NDOWS  \sy stefn32  \B00TV  I D .  d  1 1 

0xf8aaa000 

ACPI .sys 

0xf856b000 

\WIND0WS\system32\DRIVERS\WMILIB.SYS 

0xf8b9c000 

\SystemRoot \sy stem32 \DR I VERS \USBST0R . SYS 

0xf8a9a000 

NSystemRoot \system32 \dr i vers \km i xer . sys 

0xf57aa000 

\??\C : \too ls\FUTo_enhanced\FUTo_enhanced\FUTo\EXE\msdirectx .sys  Bxf BbOBOOO 

Figure  12:  Excerpt  of  results  from  Volatility  modules  option 


The  Volatility  Framework  also  allows  an  investigator  to  list  all  the  kernel  modules  loaded  at  the 
time  the  memory  image  was  captured.  While  the  path  of  the  last  entry  from  the  mo  d  u  I  e  S 
command  certainly  attracts  attention,  an  even  less  obvious  path  would  show  the  msdirectx.sys.  A 
simple  Google  search  will  show  this  module  is  associated  with  rootkits. 


The  Volatility  Framework  provided  evidence  about  the  attacker’s  IP  address  and  the  connections 
to  the  system.  In  addition,  it  provided  some  leads  in  terms  of  the  possibility  of  a  rootkit  and 
hidden  process  being  present. 


NOTE: 

After  this  article  was  written  a  new  version,  Volatility  1.3,  was  released.  Volatility  now  supports 
Windows  XP  SP2  and  SP3  as  well  as  Linux  operating  systems.  Several  new  modules  have  also 
been  added,  increasing  the  capabilities  of  the  framework  significantly. 


3.2  PTFINDER 


The  second  memory  analysis  tool,  PTFinder,  is  a  Perl  script  that  supports  analysis  of  Windows 
2000/2003/XP/XP  SP2  operating  system  versions.  PTFinder  enumerates  processes  and  threads  in 
a  memory  dump.  PTFinder  uses  a  brute  force  approach  to  enumerating  the  processes  and  uses 
various  rules  to  determine  whether  the  information  is  either  a  legitimate  process  or  just  bytes. 
Although  this  tool  does  not  reveal  anything  new  in  terms  of  malware,  it  does  reflect  a  benefit  of 
volatile  memory  analysis,  which  is  repeatability  of  the  results. 
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\io. 

Type  PID  TID 

Time  created 

Time  exited  Offset 

CR3 

Remarks 

1 

2 

Proc 

Proc 

0 

3816 

2008-07-10 

19 

49:21 

0x00551d80 

0x01f4e020 

0x0031a000 

0xla5402a0 

Idle 

cmd.exe 

3 

Proc 

3540 

2008-07-09 

21 

38:54 

0x01fb25e0 

0xla540400 

cmd.exe 

4 

Proc 

3072 

2008-07-09 

21 

37:49 

0x01fdb5b0 

0xla540320 

wuaucLt.exe 

5 

Proc 

3144 

2008-07-10 

19 

04:48 

0x01fef020 

0xla540460 

services.exe 

6 

Proc 

2616 

2008-07-09 

21 

37:39 

0x02056020 

0xla540100 

VMwareTray.exe 

7 

Proc 

648 

2008-07-09 

21 

36:31 

0x020fcda0 

0xla540240 

Rtvscan.exe 

8 

Proc 

724 

2008-07-09 

21 

36:15 

0x0217b5a8 

0xla540080 

services.exe 

9 

Proc 

1716 

2008-07-09 

21 

36:24 

0x02190da0 

0x10540200 

spoolsv.exe 

10 

Proc 

1168 

2008-07-09 

21 

36:21 

0x021a6990 

0xla540160 

svchost.exe 

11 

Proc 

1508 

2008-07-09 

21 

36:22 

0x021a9020 

0xla5401a0 

ccSetHgr.exe 

12 

Proc 

2032 

2008-07-10 

19 

52:21 

2008-07-10  19:52:22  0x021d0358 

0xla540220 

cmd.exe 

13 

Proc 

2632 

2008-07-09 

21 

37:39 

0x021d93a0 

0xla540360 

VMwareUser.exe 

14 

Proc 

2640 

2008-07-09 

21 

37:39 

0x021fdda0 

0xla540380 

ccApp.exe 

15 

Proc 

736 

2008-07-09 

21 

36:16 

0x0235a020 

0xla5400a0 

lsass.exe 

16 

Proc 

2468 

2008-07-09 

21 

37:34 

0x0235e7b0 

0xla540340 

explorer.exe 

17 

Proc 

1552 

2008-07-09 

21 

36:23 

0x023edda0 

0xla5401c0 

ccEvtMgr.exe 

18 

Proc 

1640 

2008-07-09 

21 

36:24 

0x023fd9a0 

0xla5401e0 

SPBBCSvc.exe 

19 

Proc 

656 

2008-07-09 

21 

36:13 

0X02401C08 

0xla540040 

csrss.exe 

20 

Proc 

680 

2008-07-09 

21 

36:14 

0x024205f0 

0xla540060 

winlogon.exe 

21 

Proc 

1308 

2008-07-09 

21 

36:21 

0X0242C888 

0xla540180 

svchost.exe 

22 

Proc 

1112 

2008-07-09 

21 

36:20 

0x0242cb08 

0xla540140 

svchost.exe 

23 

Proc 

1016 

2008-07-09 

21 

36:20 

0x02436bl0 

0xla540120 

svchost.exe 

24 

Proc 

912 

2008-07-09 

21 

36:17 

0x0243e250 

0xla5400e0 

svchost.exe 

25 

Proc 

1224 

2008-07-09 

21 

36:33 

0x02458da0 

0xla540260 

VMwareService.e 

26 

Proc 

3796 

2008-07-10 

19 

00:22 

0x02490170 

0xla5402e0 

cmd.exe 

27 

Proc 

896 

2008-07-09 

21 

36:17 

0x024a86a8 

0xla5400c0 

vmacthlp.exe 

28 

Proc 

0 

2008-07-10 

18 

59:55 

0x024fb020 

0xla5402c0 

MACSpoof .exe 

29 

Proc 

608 

2008-07-09 

21 

36:12 

0x02578408 

0xla540020 

smss.exe 

30 

Proc 

4 

0X025C8830 

0X0031a000 

System 

Figure  13:  Results  ofPTFinder  with  the  “no  threads”  option 


The  “no  threads”  option  on  PTFinder  gives  us  a  list  of  processes  found  in  the  memory  dump. 
Notice  the  MACSpoof.exe  near  the  bottom  of  the  list  with  a  PID  of  0. 
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2468 

file  ofs 
Ox235e7bO 

explorer.exe 

started 

2008-07-09 

21:37:34 

running 


0 

3816 

3540 

2616 

file  ofs 
0x24fb020 

file  ofs 
0xlf4e020 

file  ofs 
0xlfb25e0 

file  ofs 
0x2056020 

MACSpoof.exe 

cmd  .exe 

cmd  .exe 

VMwareTray.exe 

staned 

2008-07-10 

18:59:55 

started 

2008-07-10 

19:49:21 

started 

2008-07-09 

21:38:54 

started 

2008-07-09 

21:37:39 

running 

running 

running 

running 

Figure  15: 


Close  up  of  PTFinder  graph  showing  the  MACSpoof.exe 


PTFinder  also  has  the  ability  to  output  results  in  the  dot(l)  format.  This  is  an  open  source  graphics 
language  that  provides  a  visual  representation  of  the  relationships  between  threads  and  processes. 
(These  relationships  are  shown  in  full  in  Figure  14  and  close  up  in  Figure  15.) 
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4  Analysis 


Thus  far,  we  have  described  two  different  incident  response  approaches  to  the  scenario  discussed 
in  Section  1.2.  The  first  approach  is  the  well-known  live  response  where  an  investigator  surveys 
the  crime  scene,  collects  the  evidence,  and  at  the  same  time  probes  for  suspicious  activity.  The 
second  approach  is  the  relatively  new  field  of  volatile  memory  analysis  where  an  investigator 
collects  the  memory  dump  and  performs  analysis  in  an  isolated  environment.  In  both  approaches, 
we  described  what  types  of  information  gave  an  investigator  insight  into  the  scenario.  Now,  we 
will  discuss  some  of  the  issues  with  live  response  that  hinder  effective  analysis  of  a  digital  crime 
scene.  We  will  also  discuss  why  volatile  memory  analysis  should  be  the  ideal  approach  to 
investigating  cyber  crime. 


While  the  purpose  of  live  response  is  to  collect  all  relevant  evidence  from  the  system  that  will 
likely  be  used  to  confirm  whether  an  incident  occurred,  the  implementation  of  the  process  has 
significant  setbacks,  including  the  following: 


•  First  Responder  toolkit  may  rely  on  Windows  API:  The  problem  is  that  if  an  attacker 
compromises  the  system  and  changes  system  files  without  an  investigator  suspecting,  then  an 
investigator  could  collect  a  large  amount  of  evidence  that  is  based  on  compromised  sources. 
As  a  result,  this  would  damage  the  credibility  of  the  analysis  in  a  court  of  law. 

•  Live  response  is  not  repeatable:  The  information  in  memory  is  volatile  and  with  every  passing 
second,  bytes  are  being  overwritten.  As  we  saw  in  our  scenario,  the  tools  may  produce  the 
correct  output  and  in  themselves  can  be  verified  by  a  third-party  expert.  However,  the  input 
data  supplied  to  them  can  never  be  reproduced.  As  a  result,  this  puts  the  evidence  collected  at 
risk  in  a  court  of  law.  Therefore,  it  becomes  difficult  for  investigators  to  prove  the  correctness 
of  their  analysis  of  the  evidence.  [Walters  2007]. 

•  Investigators  cannot  ask  new  questions  later:  The  live  response  process  does  not  support 
examination  of  the  evidence  in  a  new  way.  This  is  mainly  because  the  same  inputs  to  the  tools 
from  the  collection  phase  cannot  be  reproduced.  As  a  result,  investigators  cannot  ask  new 
questions  later  on  in  the  analysis  phase  of  the  investigation  [Walters  2007].  By  the  analysis 
phase,  it  becomes  impossible  to  learn  anything  new  about  the  compromise.  In  addition,  as  we 
saw  in  our  scenario,  once  critical  evidence  is  missed  during  collection,  it  can  never  be 
recovered  again.  It  damages  the  case  against  the  attacker. 


On  the  other  hand,  a  volatile  memory  analysis  shows  promise  in  that  the  only  source  of  evidence 
is  the  physical  memory  dump.  Moreover,  collection  of  physical  memory  has  become  more 
commonly  practiced.  An  investigator  can  then  build  the  case  by  analyzing  the  memory  dump  in 
an  isolated  environment  that  is  non-obtrusive  to  the  evidence.  Thus,  volatile  memory  analysis 
addresses  the  drawbacks  facing  live  response  as  follows: 
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•  It  limits  impact  to  the  compromised  system:  Unlike  live  response,  memory  analysis  uses  a 
simplified  approaeh  to  investigating  a  erime  scene.  It  involves  merely  extracting  the  memory 
dump  and  minimizes  the  fingerprint  left  on  the  compromised  system.  In  addition,  the  nature 
of  live  response  puts  the  analysis  of  the  evidenee  at  risk  in  a  eourt  of  law.  As  a  result,  an 
investigator  gets  the  added  benefit  of  analyzing  the  memory  dump  fully  eonfident  that  the 
impact  to  the  data  is  minimal. 

•  Analysis  is  repeatable:  Sinee  the  memory  dumps  are  analyzed  direetly  and  in  isolated 
environments,  this  allows  for  multiple  sourees  to  validate  and  repeat  the  analysis.  We  saw  this 
in  our  scenario,  where  the  hidden  malware  proeesses  were  identified  by  the  two  tools.  In 
addition,  it  allows  for  conclusions  made  by  investigators  to  be  verified  by  third-party  experts. 
Essentially,  it  improves  the  credibility  of  the  analysis  in  a  court  of  law. 

•  Nature  of  analysis  supports  asking  new  questions  later:  Contrary  to  live  response,  memory 
analysis  allows  investigators  with  more  expertise,  technique,  or  understanding  to  ask  new 
questions  later  on  in  the  investigation  [Walters  2007].  We  saw  this  in  our  scenario.  Our  initial 
analysis  of  the  memory  dump  with  Volatility  gave  us  some  suspicion  of  a  rootkit  being 
present  on  the  system.  We  later  confirmed  this  with  evidence  of  the  terminated  rootkit  process 
using  the  Lsproc  script.  This  important  evidence  may  have  been  missed  in  a  live  response. 

One  of  the  greatest  drawbacks  with  volatile  memory  analysis  is  that  the  tools’  support  has  not 
matured  enough.  This  is  beeause  with  every  release  of  a  new  operating  system,  the  physical 
memory  structure  changes.  Development  of  memory  analysis  tools  has  been  gaining  veloeity 
recently,  but  the  kinks  still  remain.  This  is  an  emerging  field  and  new  ground  is  being  broken 
aeross  the  area  of  study. 
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5  Conclusions 


Despite  the  drawbaeks  assoeiated  with  volatile  memory  analysis,  it  is  the  authors’  opinion  that 
volatile  memory  analysis  will  be  integral  to  the  digital  investigation  proeess  going  forward.  Based 
on  current  technologies,  the  best  approach  is  a  hybrid  based  on  situational  awareness  and  a  triage 
mentality.  This  same  triage  mentality  is  aptly  demonstrated  by  emergency  medical  personnel 
when  dealing  with  multiple  casualties.  For  instance,  the  EMT  must  make  a  rapid  assessment  of 
accident  victims  before  deciding  on  the  priority  and  type  of  treatment.  Instead  of  being  used  to 
gather  exhaustive  amounts  of  data,  live  response  should  move  to  a  triage  role,  collecting  just 
enough  information  to  determine  the  next  appropriate  step.  Full  memory  analysis  (and  the 
requisite  memory  acquisition)  should  be  used  to  augment  and  supplement  traditional  digital 
forensic  examination  when  greater  understanding  of  the  running  state  of  the  machine  is  critical  to 
resolving  the  case.  In  other  words,  no  response  scenario  will  be  identical,  so  it  is  impractical  to 
build  rigid  procedures  and  checklists  for  use  in  the  field. 


Figure  16:  Hybrid  approach 


Rather,  an  informed  policy  should  be  developed  that  takes  into  consideration  the  various  types  of 
scenarios  that  may  necessitate  a  live  response,  memory  acquisition,  or  simple  power-off  This 
approach  falls  somewhere  between  a  typical  law  enforcement  response  and  the  techniques  used  by 
IT  staff  during  incident  response. 
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Figure  2  illustrates  the  nature  of  the  “middle  ground”  approach.  In  one  example,  live  system 
investigation  may  be  necessary  to  determine  the  presence  of  mounted  encrypted  containers  or  full- 
disk  encryption.  If  detected,  the  examiner  would  then  switch  to  capturing  a  memory  image  for  off¬ 
line  analysis  (as  well  as  capturing  the  data  in  an  unencrypted  state).  A  memory  image  allows  for 
the  application  of  analysis  tools,  now  or  later,  which  can  extract  valuable  cryptographic  material. 
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